home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Turnbull China Bikeride
/
Turnbull China Bikeride - Disc 2.iso
/
ACORNUSERS
/
EMULATOR
/
MAME34
/
RISCOS.TXT
< prev
next >
Wrap
Text File
|
1998-10-26
|
49KB
|
1,123 lines
ARM/RISC OS MAME, version 0.34 beta 5.2, ported by Gareth S. Long
=================================================================
Last updated: (26 Oct 1998)
** PLEASE READ THE CHANGELOG AT THE BOTTOM OF THIS FILE FOR IMPORTANT
UPGRADE INFORMATION, ESPECIALLY IF YOU ARE NOTICING DIFFERENCES BETWEEN
THE CURRENT MAME AND YOUR LAST VERSION **
** PLEASE ALSO READ THE ACCOMPANYING README.TXT AND WHATSNEW.TXT RELATING
TO MAME, ESPECIALLY THE BITS AT THE TOP IN CAPITAL LETTERS, IN MUCH THE
SAME WAY AS YOU ARE READING THIS NOW **
AND READ THEM EVERY TIME THIS FILE IS UPDATED.
*** PLEASE, PLEASE, PLEASE MAKE SURE YOU ACTUALLY DID THE ABOVE ***
... I'LL BE ABLE TO TELL...
One more note: People doing magazine articles and things; please let me know
in advance! Publishers lead times mean you're probably writing a retro retro
into the world of retro gaming by the magazine hits the subscribers even. I
can give accurate information on events to coincide correctly with
publication dates.
What is it?
===========
Welcome to ARM MAME, the Multiple Arcade Machine Emulator. MAME is a large
modular emulation system which allows a relatively huge number of classic
arcade machine PROM images spanning several different games motherboard and
chipset types to be emulated and run successfully. The upshot is that you get
the chance to run original Arcade games *exactly* as they were; you *are*
playing the coin-op version, and no substitute. As a result, and rightly so,
MAME has generated a huge worldwide following, spawning tens of dedicated
web pages with hundreds of links relating to various aspects of MAME, from
ROM image addresses and screenshots, to technical information, to
reminiscences from people who mis-spent almost their entire youth and some
way beyond in a dingy chipshop playing pacman, or who were beaten to within
an inch of their lives by an angry cafe owner for breaking a Robotron 2084
joystick, or something.
MAME is the largest emulation project currently in existence, many people
having contributed drivers, information, etc, towards it's development. MAME
is, as a result, constantly in a fluid state, usually undergoing 3-4 revisions
a month, each revision usually adding an average of 25 games to the 'supported'
list. This has changed a little recently, with a drive towards higher initial
game emulation quality. This now means that newer MAMEs are released every 2-3
months, however, the nnumber of new games supported per release now stands at
around 150! Typically, two new game drivers are added to MAME a day.
This port is intended to provide all the functionality of MAME for RISC OS.
Where applicable, each of the features available to, say, MS DOS is available
for the RISC OS port too.
It's also a bit good.
The documentation for MAME should have arrived within this archive (as well
as a copy of the distribution license) - the MAME documentation is fairly
generic but has some DOS specific stuff towards the end. The RISC OS setup
instructions are given below.
What do I need?
===============
Best results are obtained with a StrongARM based Risc PC. Sorry, but versions
of MAME for other machines are only really usable on a 486DX100 or similarly
specced machine, or above for some games. Having said that, ARM 710 users
shouldn't have much of a problem with most games. I am committed to making
MAME more usable on lower-ended machines. Honestly:
MAME will work on older machines, but the palette will be completely wrong at
the moment for reasons I will describe below. Expect this to change soon,
however.
Picking up the game PROMs
=========================
These are fairly widely available via the internet. In order to use the games
legally, you should in theory own the original game machine boards (I do for
many of them, yes really :-) ) and you shouldn't just go picking them up via
sites like http://www.davesclassics.com .. so I'm sure you won't.
Organising MAME
===============
This will change a great deal as frontends for MAME are developed and put
into play, and als0o as MAME itself evolves..
Create a directory called MAME somewhere on your hard disc. I *strongly*
recommend that this directory be an image filing system archive (zipfile or
TBAFS archive will do nicely, as will a DOSFS partition.. public domain
utilities like X files etc also work well. You can even use StrongHelp to
archive the files inside a new StrongHelp manual). This allows you to use
more than 77 filenames in a directory, and also allows you to use filenames
greater than 10 characters, which some games need)
Unpack the contents of the MAME archive into it.
Create two blank directories, called 'CFG' and 'HI', alongside the MAME
executable.
Unpack any games you have downloaded into directory names which match the
game name (like 'pacman','dkong' etc). These should be subdirectories within
your MAME directory. Your resulting directorystructure should look thus
(names in square brackets are directory names):
[MAME] (image filing system archive)
\
\
MAME (executable) MameVox2 EmUtils [ROMS] [CFG] [HI] [... etc]
|
/--------------\
[pacman] [invaders]
| | |
pacman/a invaders.e ...
pacman/b invaders.h ...
pacman/c invaders.g ...
... ... ...
To run MAME, set your current directory to that of the MAME image filing
system ardchive (double clicking on the provided SetDir obeyfile will do this
for you).
Note that as of MAME 0.30.1, front ends/you are able to change the directory
paths. As a result, you can also use a RISC OS search path, enabling ROM sets
to exist in multiple directories, which gets round the problem of otherwise
having a limitation on the number of ROM directories you can have if you
don't use an image filing system like SparkFS.
Furthermore, MAME 0.31 and above have direct zipfile support built in,
meaning you can download a zipfile from the net, and it will treat this as a
directory regardless of whether you have SparkFS loaded or not. In this case,
SparkFS will be used if the file is stamped to 'DDC' or a directory image,
if it is typed as 'data', the internal Zip routines will be used.
If you want sound, double-click on the SetVox obeyfile.
Ensure you have a large wimpslot set - drag the next slot so that it's at
least 6 Megabytes - many games supported now need over 10 MBytess to run. Other games
will need more.
Press f12, then type 'mame <gamename>' (eg 'mame dkong', 'mame zaxxon' etc)
Some generic keys are:
3 Insert coin (pulse to coin mech 1, more specifically)
1 Start 1 player game
2 Start 2 players game
Tab Enter dip switch, key and joy settings, and credits display menu
Pressing TAB again returns you to the emulator, ESC will exit from MAME.
P Pause
F3 Reset
F4 Show the game graphics. Use cursor keys to change set/color, F4 to exit
F8 Change frame skip on the fly (60, 30, 20, or 15)
F9 To change volume percentage thru 100,75,50,25,0.
Keypad PLUS and MINUS change the volume with fine granularity
F10 Toggle speed throttling
F11 Toggle fps counter
F12 Save a screen snapshot
numpad +/- Volume adjust
left shift + numpad +/- Gamma correction adjust
ESC Exit emulator
Note that running mame with the '-cheat' option allows you to use the fairly
extensive cheat facilities available.
Remember that with MAME 0.28 and below, dip switch/key settings are *saved*
in the game directory as a */DSW and *.key (etc) files (MAME 0.25 groups it
all into a /CFG file)... You can remove these to reset to the defaults. Some
upgrades to MAME (particularly those up to 0.25) will necessitate the manual
removal of these files. Note that the generic ReadMe file always warns you to
do this. Warnings in this file will almost always also apply to the RISC OS
version.
MAME 0.29 and above store the CFG and HI files in their own directory,
alongside, but separate from the games directories, see the hierarchy chart
for where to put these two blank directories - they will become filled as you
play more games.
Have fun.
Other options
=============
MAME takes a veriety of options other than just the game name. All the
generic MAME options are supported, all the applicable DOS options are
supported, and there are a few RISC OS specific ones. These are as follows.
-320 tell MAME to use a vesa 320x240 video mode
-320x256 same as above, video mode is 320x256
-512 same as above, video mode is 512x384
-640 same as above, video mode is 640x480
-800 same as above, video mode is 800x600
-1024 same as above, video mode is 1024x768
-1280 same as above, video mode is 1280x1024
-1600 same as above, video mode is 1600x1200
-XxY where X and Y are width and height (ex: 800x600) (not yet implemented)
-vsync synchronise video display with the video beam instead of using
the timer. This works best with -noscanlines and the -vesaxxx
modes. Use F11 to check your actual frame rate - it should be
around 60. If it is lower, try to increase it with -vgafreq (if
you are using a tweaked video mode) or use your video board
utilities to set the VESA refresh rate to 60 Hz.
Note that when this option is turned on, speed will NOT
downgrade nicely if your system is not fast enough.
-rotate No longer supported by any MAME.
-nojoy don't poll joystick (not really needed with RISC OS)
-log create a log of illegal memory accesses in ERROR/LOG
-list display a list of currently supported games
-help, -? display current mame version and copyright notice
-list display a list of currently supported games
-listfull display a list of game directory names + description
-listroms display selected game required roms
-listsamples display selected game required samples
-verifyroms check selected game for missing and invalid ROMs.
-verifysamples check selected game for missing samples.
-romdir specify an alternate directory where to load the ROMs from (deprecated)
-mouse, -nomouse enable/disable mouse support
-trak enable trackerball emulation support
-frameskip n skip frames to speed up the emulation. For example, if the game
normally runs at 60 fps, "-frameskip 1" will make it run at 30
fps, and "-frameskip 2" at 20 fps. Use F11 to check the fps your
computer is actually displaying. If the game is too slow,
increase the frameskip value. Note that this setting can also
affect audio quality (some games sound better, others sound
worse). Maximum value for frameskip is 3.
-ror rotate the display clockwise by 90 degrees.
This implies '-vesa -800x600' if not specified otherwise
on the command line. It also provides authentic *vertical*
scanlines, given you turn your monitor to its side.
CAUTION:
A monitor is a complicated, high voltage electronic device.
There are some monitors which were designed to be rotated.
If yours is _not_ one of those, but you absolutely must
turn it to its side, you do so on your own risk.
******************************************************
PLEASE DO NOT LET YOUR MONITOR WITHOUT ATTENTION IF IT
IS PLUGGED IN AND TURNED TO ITS SIDE
******************************************************
-ror rotate the display clockwise by 90 degrees.
-rol rotate display anticlockwise
-flipx flip display horizontally
-flipy flip display vertically
-ror and -rol provide authentic *vertical* scanlines, given you
turn your monitor to its side.
-cheat Cheats like the speedup in Pac Man or the level skip in many
other games are disabled by default. Use this switch to turn
them on.
-voices <n> use <n> channels for RISC OS sound. Values are: 1,2,4 and 8.
-doubley use scanline doubling (useful if MAME is pickking a mode which
'letterboxes' with your monitor type - MAME will pick a larger
mode but stretch the video image in the Y axis.
-gappy This is only useful with -doubley. This gives 'gaps' between the
doubled-up scanlines to give a more authentic effect.
-hz <freq> Force only monitor definitions conforming to <freq> freqnecy.
Find something else if it can't find that freqency for the
given resolution. Default, or -1 is Wolverhampton
female on a Friday night.
-fm/-nofm (default: -nofm) on other systems, this means 'use the SoundBlaster
OPL chip for music emulation in some games. This would be faster,
with less faithful emulation, but we don't have soundblaster OPL.
-romdir specify an alternate directory where to load the ROMs from
-normalrefresh (default)
-directrefresh
-bankedrefresh
These allow direct screen access (or bankswitched direct screen access)
instead of the usual MAME blit technique (-normalrefresh), thus speeding
the game up a little on slower systems.
This will not work with some games, however, and banked/directrefresh are
best used in conjunction with -vsync.
-vg is no longer supported. It's now the default when using
vector games.
-antialias/-noantialias (default: -antialias)
-beam n sets the width in pixels of the vectors. n is a float in the
range of 1.00 through 16.00.
-flicker n make the vectors flicker. n is an optional argument, a float in
the range range 0.00 - 100.00 (0=none 100=maximum).
-cheat Cheats like the speedup in Pac Man or the level skip in many
other games are disabled by default. Use this switch to turn
them on.
-debug Activate the integrated debugger. During the emulation, press
tilde to enter the debugger.
-record nnn Record joystick input on file nnn.
-playback nnn Playback joystick input from file nnn.
-savecfg save the configuration into mame/cfg
-ignorecfg ignore mame/cfg and start with the default settings
-record Record joystick input on file INP.gamename/inp.
-playback Playback joystick input from file INP.gamename/inp.
-depth n (default: 16)
Some games need 65k color modes to get accurate graphics. To
improve speed, you can turn that off using -depth 8, which limits
to the standard 256 color modes.
Unless you specify otherwise, MAME will attempt to pick the correct display
resolution for you given your monitor type, and choose the next nearest if
that fails. Most games require 224x288. holding down CONTROL during startup
will allow you to see some of the diagnostic messages giving information on
what mode MAME found suitable.
On a Risc PC, you can define your own modes using !MakeModes to make the best
use of your monitor.
The best method of setting up perfect modes for MAME are as follows:
1) Get a copy of something like !MakeModes, !CustomVDU or whatever, from any
good Acorn-related FTP site (!MakeModes is available from ftp.acorn.co.uk).
2) Define a mode of either the exact size you need (eg 224x288) or one with
*twice* the Y resolution so that you can use -double (and -scanlines if you
like) - modes defined this way are likely to have a lower refresh rate and
might perform a little better.
It doesn't take an experienced modesman to define up a mode that'll work fine
with your monitor type - just fiddle with a resolution reasonably close to
what you're aiming for. Pass your examples of professional modesmanship to me
and I'll include them with the distribution, I shall provide some
ready-made monitor definition files I've defined for common monitortypes
soon.
To Do
=====
'Acceleration' of vector graphics.. this is something other ports don't have yet
(which surprises me).
-desktop operation.
The TurboMAME module, which, when loaded, provides alternative 6502 and Z80 emulation
for RISC OS MAME, speeding it up somewhat and making it much more usable on non
StrongARM based machines.
History
=======
A list of doings that have been transpiring, from the beginning:
[07 Jun 1997] (MAME 0.23)
Started. Came in late from a nightclub. Sat down with pizza box. Got the MAME
code to compile and made a start on the operating system dependant stuff.
When I came to next morning, I found there was some kind of video support.
[09 Jun 1997]
Added keyboard support (buggy). First release made available to a few people.
[11 Jun 1997]
Started on the sound code. Sorted out some keyboard issues.
[15 Jun 1997] (MAME 0.24.0)
Notice 0.24 MAME sources are available, so grafted them in. I'll always try
to ensure ARM MAME uses the absolute latest MAME source available.
[22 Jun 1997] (MAME 0.24.1 extreme beta)
First version with limited sound support. Limited as in it doesn't actually
work very well at all. Words cannot describe how much the sound system is
annoying me. I have to work with sound tables as small as 16 bytes. It's
nasty.
[24 Jun 1997] (MAME 0.24.1 beta 2)
Sound is improved a little. Not that much, though. Certainly not enough.
Damn. better screen mode selection code (well.. it's got mode selection
code). This actually works well, though you're bets off defining some modes
as old arcade machine resolutions are a little B'zarre.
The problem with setting DIL switch options via TAB, and cycling game
graphics/colours has been fixed.
[26 Jun 1997]
Stuff was done. Lots and lots of it. Also, I got round to doing some things
too. I wondered if the things would get in the way of the stuff, but
thankfully I seemed to manage both. I must have too much time on my hands or
something. Anyway, the collection of things and stuff included:
Scanline doubling support!
Gapped scanline doubling support too.
Game graphics are now centralised within the mode if the mode is larger than
the games' resolution.
Sound should be a lot better :-) (woohoo) Still not right though (D'oh)
I wrote some documentation. It'll be the stuff you're reading right now. You
lucky, lucky people.
[29 Jun 1997] (0.24.1 beta 3)
More work on sound, it should at least play on systems now. Let me know if it
doesn't.
The invaders/h problem has been worked on. All game PROMs should now be
converted whether they are given names like invaders.h, invaders/h or
h.invaders. Lahvly. In theory.
[01 Jul 1997]
Made mode selection less fussy (IE it won't give up on a resolution if it
can't find it at the ideal framerate any more)
Improvements to sound
Williams Electronics Driver colour cycling implemented - this wasn't done
before because the code to drive the DOS version directly isn't really in the
right place in the MAME source (in the operating system dependant part of the
code), and I was hoping it would be fixed in 0.25 but it wasn't.
[02 Jul 1997]
Merged in 0.25 MAME sources.
Sound is better...
Sorted so all the erroneous osdependant stuff hanging around in the MAME
source code is worked through to my RISC OS stuff..
Because the vsync rate is so high in some monitor def files, I added the -hz
option so people can force a specific frame rate for now (dropping to another
mode if it can't get it) this is because constantly waiting on vsyncs which
are happening all the time (when there's little backtrace time to do anything
else) slows games down somewhat. The fix is really to try to define lower
frame rate mdf's if you can, or define a double-height mode and use the
-doubley option.
[05 Jul 1997]
Linked with updated C library. This at least changed the problem people were
having with inability to load game files.
[08 Jul 1997]
Turns out the above game directory search failiure is down to a bug in either
the OS, FS or library code. It's hard to find as only 3 people to my
knowledge have the problem and I can't for the life of me repeat it. Anyway,
let me know what this one does, as I should have worked around it.
Sound is now much improved.. no, really (!)... sound streaming also supported
so a *lot* more games now have sound, especially if you've picked up the .sam
files to go with the ROM images.
-doubley won't give up so easily finding a double Y res mode, so exceptions
shouldn't happen here anymore.
Overall volume setting implemented.
Mouse control implementation has begun.
[11 Jul 1997] (0.25.3)
Linked with a completely different library. Executable should now be a few
hundred K shorter and a bit faster, and I believe all the name problems have
finally gone.. whopee.
To get your images in order, just ensure names like pacman.6e are copied
as pacman/6e - that's it. Easy, huh? All archive filings systems will do that
for you as it's standard.
[16 Jul 1997]
Got 0.26 sources. Ported. Found 0.26 sources had problems...
[17 Jul 1997] (0.26.0)
Okay.. 0.26 is basically fairly shagged. The problem appears to be memory
corruption within the MAME code itself (d'oh) - it's apparently with the PC
version as well, so it appears I am not to blame (woohoo/d'oh).
All I can say is you'll find some things work better than before, the new
games supported seem to work okay, but some won't play at all at the moment.
For this reason I've included the mame025 too - sorry! I'll fix it as soon
as I know what is happening, but I suspect there will be a quick rerelease of
MAME. Bear in mind that as I type this, only RISC OS and PC versions of MAME 0.26
exist.
-nosound has been added.
A bug was fixed in the sound support (some samples will no longer erroneously
repeat like they were doing in MAME 0.25).
[18 Jul 1997] (0.26.1)
A bugfix release of MAME 0.26 (0.26a) was released and I ported this version across..
This version works, supports one or two more games than 0.26 did, and fixes colours
with some games.
Pacman pitch is different - note that this is due to a change in the generic MAME
sources though there have been some slight sound changes by me recently.
[20 Jul 1997]
Tested and released. In theory any remaining keyboard problems have been
sorted out.
Please note that the generic source for version 0.26.1 of MAME is still not
correct - this has been experienced by PC users (the only other version of
MAME 0.26 right now is the PC version) - games like Pengo and Yie Ar Kung Fu
are experiencing the same problem as with 0.26.0.
Also, for some games, you are recommended to use the -nosound option - the
generic code for 0.26 seems to be hanging at the point where it's supposed to
generate wave forms to play - to get out of the hang, alt-break and then
rerun mame and then exit in order to clean up the sound system.
I am awaiting a newer bugfixed version of MAME 0.26 to port.. :-)
[07 Aug 1997]
Work on newer sound system - designed to take what I've got so far and
generate a more unified SoundBlaster-style API for RISC OS. Once I've grafted
this in, all remaining sound problems should be cleared up.
[11 Aug 1997] (0.27.0)
MAME 0.27 arrives at last :-)
Ported across. There is a lot more I want to do as I have finished my other
changes. Essentially I am releasing this to get any major bug problems so I
can try to fix them at the same time as grafting the new sound system in.
If you are having problems with hanging with some games, *RMKill MameVoices
before running the emulator.
-vg not implemented yet.
[12 Aug 1997]
-vg implemented. Vector games seem to run very nicely in 800x600 or even
1280x1024 modes.
[15 Aug 1997]
New Sound module! It works extremely well so sound in everything is
significantly improved.
The sound module is actually a very cut down version of the new sound API I'm
developing, as RISC OS sound support has started to become the bottleneck for
RISC OS MAME at the moment. My sound system will allow for 32 channels with
mixing, Each channel can have it's own frequency, waveform, volume, and
looping points. It has support for 8 and 16-bit sound systems, and optimises
itself towards the system in use.
The system is a sharable resource and I shall be using it myself for future
projects. I shall release the API to other developers when it's further
developed.
Put back the Williams video driver hardware palette change optimisation which
was missing from MAME 0.27.0 (I hadn't noticed they'd correctly
conditionalised hardware palette availability at compile time at long last,
rather than #defining MSDOS_ONLY in the Williams video hardware emulation
file for hardware palettes - which is why very early versions of MAME had
broken palettes for Williams stuff. Williams driver is now, as a result, back
to pre-2.7.0 speeds again.
[20 Aug 1997]
Added additional optimisation to Williams driver (IE RISC OS is nearer the
Win32 DirectX5 model, so now only one screen blit is needed, not 2 (like
DOS) or 3 (like Unix). Williams drivers are now extremely fast.
[21 Aug 1997]
Minor tweaks to streamed sound.
Mouse support is now working. This behaves in the same way as the DOS/Win32
version.
Overall volume control works fully.
[22 Aug 1997] (MAME 0.27.1)
Trackerball emulation support added (-trak) - makes Missile Command
infinately more playable :-)
[25 Aug 1997]
Started work on two new refresh algorithms, -directrefresh and
-bankedrefresh, allowing direct screen access (or bankswitched direct screen
access) instead of the usual MAME blit technique, thus speeding the game up a
little on slower systems. This will not work with some games, however.
[09 Sep 1997]
MAME 0.28 source acquired and ported across. This includes the new MAME 68000
simulation core.. unfortunately, under ARM, this is
sloooo-oooo-oooo-oooo-oooow, to say the very least. The biggest problem is
that the 68000 is bigendian, and works with halfwords (as we know them in the
ARM world - ie they are 16 bits).. later ARM architectures allow halfword
stores (woohoo!) but IOMD(+)/7500FE does not (d'oh!). We're lucky to have an
inexpensive barrel-shifter, as the emulator uses it as if it's going out of
fashion. Most of the time it's taking a trip into
shiftleftbytwentyfourbitsville.
I found the problem with sounds with some games under RISC OS (and other
versions but it only really appeared with the RISC OS version). Basically the
PSG AY-3-8910 sound generator was partying on down with the memory map with
the fervour of a Cwmbran Nurse. I'll reflect my changes back to the other
MAME-type people, but I suspect I still have some work to do here. In fact, I
definitely do, as this chip emulation is also the reason behind some games
appearing to 'lock' if sound is enabled.
[10 Sep 1997] (MAME 0.28.0)
Tidied and released.
The executable size is up by around 600K as a result of the changes made to
0.28. The inclusion of the 68000 emulator should result in an explosion
of extra games supported very soon.
[15 Sep 1997]
Found a problem with speed throttling under RISC OS - IE it doesn't work.
Basically, ARM MAME has been running too fast and without throttling until
now. The problem is due to RISC OS by default not providing a timer with a
greater resolution than 100 ticks a second. Correct speed throttling requires
a millisecond timer which I have to implement myself when I have the time
(and I'm very very busy with other projects at the moment I'm afraid...)
Speed throttling is now implemented which means games run at the correct
speed. To return to the speeds you're probably used to by now, turn speed
throttling OFF.
Actually, speed throttling won't be quite perfect until I implement a
millsecond timer, the lack of accuracy in the centisecond timer means that
you'll end up being just under or just over 100% speed (the little 'gaps' it
fills in by waiting in order to throttle the speed can be much smaller than a
centisecond).
[23 Oct 1997] (MAME 0.29.0)
Sorry if this one appeared relatively late (48 hour wait.. sorry ;-) ).. I'm
currently up to my eyes in another project at the moment and ported this for
stress relief..
Actually this one was quite complex to port due to the large numbers of
changes going on at source level - there are however a lot of generic
enhancements in this release.
Slot size is up again I'm afraid - there's another processor (6808) being
emulated too, bringing the total amount of currently emulated processors to
six.
Executable size is around 1600K.
[31 Oct 1997]
Released...
[03 Nov 1997] (MAME 0.29.1)
Problems fixed within MAME which now result in significant improvement of
graphical quality in some games (specifically we were falling foul of the
word-alignment problem with ARM loads and stores, or halfw*rds but I don't
even want to begin to talk about them).
Games such as StarForce, Rastan, tp84, Kangaroo etc now look far far better, and
don't suffer the effect of.. well, nonaligned data loads being blitted to memory
and doing all sorts of strange shimmering effects when you move, like some kind
of shimmering strange effects-sort-of-thing.
I've also finally got in touch with Mirko Buffoni (the MAME co-ordinator and
also a very very very nice and enthusiastic bloke) to get some of the ARM
version changes necessary merged into the generic MAME sources... this should
save time for me in the future.
A similar word-alignment problem has been fixed with the 68000 driver.. so
Rastan works agaiu and at twice the speed it was before.
The MAME executable has been Squeezed.. This knocks about 900K off it during
storage...
[10 Dec 1997] (MAME 0.29.2)
Recompiled with CLib again, UnixLib seems to be causing random file opening
problems with some people, probably down to something underlying in RISC OS.
Damn.
Correct whatsnew/txt etc files.
MAME is no longer squeezed - I remembered why I didn't do it in the first
place now, it adds to the size of the archive, and, as I recommend storing it
in an archive anyway, it just causes an increase in space taken for most
people.
Some other minor bits and pieces tweaked.
Placed the whole lot in a more ready-to-run directory structure.
[14 Dec 1997] (MAME 0.29.3)
Lots of little fixes:
Implemented dirty buffering for this release. This speeds some games up (more
in the future) significantly. A nasty bug in ARM GCC had stopped me being
able to do this before (ARM GCC sometimes doesn't store registers on the
stack with some functions, and you can end up with BL ... followed by MOV
pc,r14).
Dirty buffering will probably improve further in the next release.
Found the problem with sound hanging with some games (eg Star Wars, Missile
Command, Centipede, Asteroids Deluxe); it was the POKEY emulation doing
non-word-aligned 32-bit loads and stores.
Mouse positioning problems fixed.
[08 Jan 1998]
MAME 0.30 source finally arrives.
Fixed very minor bug in pokey sound generation introduced when I cleaned it
up for ARM word alignment in December. This improves sound in a few cases.
-320 was setting the wrong display mode. Oops.
[09 Jan 1998] (MAME 0.30.0)
Tidied in preperation for release. Config loading and saving to a file will
be disabled in this release until I get some more feedback from frontend
authors so we can use a file format which makes everyone happy. It'll
probably end up as a textual keyword file.
The distribution archive now contains some cheat codes for the cheat system.
Anti-Aliasing now working with the vector games. Anti-Aliasing is
automatically turned on with high resolutions; you can use -noaa to turn it
off.
There has been a fantastic deal to do this time, I've tried a lot of games
and they worked.. I could not test all of them to say the least. Please let
me know of any problems. I know I have a lot to do as far as sound is
concerned, this will be my next task.
Executable size is around 2360K now.
[10 Jan 1998]
CFG/HI loading/saving mechanism fixed.
Loading and saving of cheats sorted.
Placed some modelists in the modelists directory...
Pitch flattening problems in Galaxians etc have been fixed, also, sound
streaming is improved, which should work towards the 'choppiness' you
sometimes get with sounds. This is still largely dependant on your machine
speed, frame skip rate configured, etc. Please note that as a result, the
MameVox2 module has been upgraded - it'll all sound screwy if you use the
old one.
Sound streaming is not perfect yet.
[11 Jan 1998]
Damn. My ARM MAME page has been moved onto the restrictred resource page by
Demon due to the large number of hits I'm getting for each ARM MAME release.
Avtually, even the speculative hits (people checking for a newer version) are
causing my bandwidth limit to be exceeded.. thus, I'll need to find a new
server soon...
-fm and -nofm work properly now. As this command is based on the same switch
for other systems, it works oppositely to what you might expect - ie -fm
actually means 'use hardware FM' - we don't have hardware FM synthesis. -nofm
means use software frequency modulation synthesis, so for us, -fm means don't
use have any FM synthesis at all (which is much faster), and -nofm gives us
FM music etc support, but at a cost in terms of speed.
[12 Jan 1998]
The mame/cfg and -usecfg/-savecfg options are implemented. For front end
authors, MAME creates defaults and loads and save the information to mame/cfg
in the same directory as the Absolute file. The file is a standard INI
format, allowing chunks and comments and so on. This behaves in more or less
the same way as the DOS version of MAME.
Note that the default is now to store ROMS in <current directory>.ROMS,
however it will try the place we're used to first, as well as trying /zip
subdirectories due to image filing systems.
[13 Jan 1998]
Vector Anti-Aliasing setting options now saves more sensibly than the DOS
version, especially if auto is set (which is the default).
Auto Anti-Aliasing mode works correctly - IE it turns on Anti-Aliasing
automatically for sizes greater than or equal to 640x480 resolution.
Please note that, as MAME progresses, emulation of some games may appear
slower; this is usually the result of something additional being emulated
within that game - often sound is improved in that a whole sound processor is
being emulated, or extra scroll layers are added to game which it lacked
before, or the default resolution gets higher, or it was simply running too
quickly before because the timings were got wrong. Please remember that in
almost all cases, you are able to disable some of the extra hardware
emulations added during MAME revisions, so you can revert back to old
behaviour - or if you want to dabble in getting the best out of both worlds,
you have options like frameskip, or screen size selectors to play with.
[02 Feb 1998]
General tidying, and sorting out the cheat mode hassles.
[17 Feb 1998] MAME 0.30.2
This was a quick test release to prove the new streamed sound code, which should
(and was) a great deal better for people.
MAME 0.31
Following this point work began on the 0.31 beta series 1-17, and release
candidate 1. Various updates and improvements have been effected (for
example, the LED toggling for reflecting player select lamps), too many to
list, and generally not dated. Huge changes have been made to the operating
system dependancies in order to support MAME 0.31's various extra features -
0.31 has the greatest list of internal changes so far, covering the addition
of 16 bit colour depth support, etc. The documentation has been reworked to
include all of this as well, so it may be useful rescanning this whole
document even if you have read it fully before.
[10 Mar 1998]
EmulatorUtilities module started. A timer of high enough resolution to
support accurate throttling within MAME, using the hardware timer system, has
been implemented first.
RMLoad EmUtils before running MAME to take advantage of the new timer code.
[24 Apr 1998] Release: MAME 0.31.0
Final version of the MAME 0.31 source code received from Nicola, and ported.
I have very very little time to test this release with the final code.
Please note that I am flying to the USA tonight (24 Apr 1998) and will be
away for two weeks. Please continue to send your queries, comments, etc, to
my standard address, I can still read them and reply whilst I am away, though
the emulator mailing list will appear to 'pause' for the duration of my
holiday.
The source weighs in at 2899K.
[29 May 1998] Release MAME 0.33 beta 3.1
Too many changes and things going on over the last few days to do a great
deal to this readme file unfortunately, so for now please check up on latest
changes and commandline/config options and differences in the generic readme
files provided. Problems with configuration should be sorted now, and many
changes have been made to the video system, allowing you to do sexy things
like choose modes smaller than the game, and then pan the screen if you want
to.
Please note that the mame/cfg choices are now stored in <choices$write> -
make sure this variable has been set up by your !Boot configuration (which it
should have).
Delete any existing mame/cfg files, as advised in the generic readmes.
-doubley and -gappy are gone; now there is a generic name for them, use
-double and -scanlines respectively. This helps to unify us with our
architectural brothers and attempt to maintain a level of synchronicity in
this big old world.
The defaults set by MAME are nodouble (not auto or on) to maintain
compatibility with what you are used to in the RISC OS world. This does mean
that vector games, by default, run in a rectangle in the centre of the
screen. Use -double to use the whole screen. This is correct, though I'll
reconsider doubling set to auto when I can get some feedback from you
regarding when we use doubling and don't, in an automatic sense.
I HAVE REMOVED ZIPFILE SUPPORT FROM THIS VERSION. It's too unstable in beta
33.3. Actually, it can be activated, if you do see it working for some reason
on your machine, let me know, because you could be the missing link and not
know it. Also, -verifyroms can cause instability in a few cases where the ROM
images are corrupt. Caution is advised, I need to speak to a few people about
their respective dogs in this department.
Oh, and look out for MESS :-) http://www.elecslns.demon.co.uk/MESS, and
http://www.davesclassics.com for more details as and when they arrive (very
soon, probably very mucharound the time you read this).
Mr. Hankey's Christmas special was so brilliant, it was profound.
I've thrown in some extra games which probably aren't in the DOS 0.33.3
release. This includes a whole new CPU core over 0.31 - the T11, used in
paperboy. Please note that the paperboy driver is very preliminary, and I
know some of the colours are inverse :-)
Executable size is around 3.5 Megs. Well, look at the games and hardware it
supports :-)
Contrary to other versions, I will still provide end-user support for beta
releases. Aren't I nice?
There will be a new beta of 0.33 (4) very soon. Almost sooner than soon.
Please contact me if you have any problems as per usual.
[17 Jun 1998] Release: MAME 0.33 beta 6.1
This is the 0.33 beta 6 release, with some extra additions made to fix
problems found with the DOS beta 6 release.
Please note the changes to the way ROMs are grouped due to 'clone' games,
this is mentioned in the whatsnew file. Similarly, some ROM sets now require
extra colour PROM files.
Various changes to the filing system code, which should work much more the
way people expect it to :-)
Zip file loading is now fully supported - you can use image filing systems as
normal to override this. Files found which aren't directory images or normal
directories will be opened as zip files. Zip Deflate or store is supported
(as with the other versions of MAME).
Some minor bugs in the video selection code fixed, for example, mode
selection when you have a monitor definition which provides a mode of the
exact size needed.
I still haven't had time to properly sync this file with reality (and provide
a core for my MESS documentation too) - you are advised to check what's new
in the generic whatsnew and readme files, all the new DOS operations are
supported.
-verifyroms works fine in this release...
Cheats should now work properly, I've finally nailed the compiler problems in
this respect.
The object code currently weighs in at 3900K, with two new CPU cores over the
last release - the Signetics 2650 and Intel 8085.
Next changes should involve a rewrite of the sound system to handle more than
8 voices, and 16 bit sound...
[23 Jul 1998] Release: MAME 0.33 beta 7.1
This is the 0.33 beta 7 release, with some extra additions made to fix
problems found with the DOS beta 6 release in the day since it was released.
628 games are supported in the RISC OS 4085K executable.
ROM name selection is now case independant in the RISC OS version - IE
mame PACMAN, mame Pacman etc, work, not just 'mame pacman'.
When games with odd screen widths are selected, RISC OS MAME now attempts a
screenmode with an even number of pixels (IE the game's width + 1) for exact
mode selection, to help people generating exact sized RISC OS mode
definitions.
There are probably some other fixes I've forgotten about; I won't document
them here yet because I've forgotten them. I will when I remember them.
Please note that there are descrepancies between the command line information
described at the beginning of the document and the current case; I am currently
reworking the documentation for my emulators and this ifile is based on slightly
older information. You should always check the generic MAME documentation anyway,
this will provide you with a list of the new features which have come about in this
release.
This will be the last MAME version to use the MameVox2 module, in future with
my emulators, there will be a separate 8 and 16-bit sound system module for
you to use instead.
[17 Aug 1998] Release: MAME 0.33 FINAL
Note that DACSpt8 and DACSpt16 are used for this version of MAME. Currently,
16 bit support is disabled, so only the DACSpt8 module is present.
Various minor fixes to the video selection code to handle the vast number of
new options recently.
[17 Aug 1998]
Various documentation changes.
There are now 10 levels of frameskip available (0-9).
Frameskip value is shown within the speed indicator.
The next release is likely to coincide with the optimisation drive throughout
the core to benefit performance on ARM-based systems. This should hopefully
significantly improve speed. Recently, floating point activity has increased
within the project to the detrement of ARM-based systems, I will try to
reduce the effects of this as far as I can.
[18 Aug 1998] (0.34 beta 1.0)
Busy, huh? ;-) Well, if you think it meant just a recompile, think again.. it
takes quite a few hours to compile, for a start, and the osdependencies had
some large changes too.
Fixed screwy dates problem with the last entry in this readme file ;-)
Use <shift> to get past the initial pages...
This executable weighs in at around 4.3 megabytes.
[01 Sep 1998] (0.34 beta 2.1)
Various small fixes
Keyboard handling improved - you can now use ENTER for game play :-)
Executable size weighs in at around 4.5 megabytes.
[17 Sep 1998] 0.34 beta 3.0
Slight changes to the file IO code as well as the usual OS dependency changes.
Added RISC OS sprite screen save support.
Unreleased due to lack of time.
[16 Oct 1998]
Grafting in major changes to OS dependencies
[20 Oct 1998]
Newer, faster screen update routines, based on 16x16 dirty grids
[23 Oct 1998]
file IO routines rewritten completely. Many bugs fixed.
Changes made to DAC support (included frequency divisor in variable fields), module upgraded to 1.30.
'Tilde' key (left of 1) fixed for on screen display functions.
[26 Oct 1998] MAME 0.34 beta 5.2
I've made a change to the way zip files are detected and treated.
Previously (IE after the Friday 23 October 1998 update) directory searches for game PROMs
would happen like this (we'll use pacman as an example here):
1) Check for a directory (either a normal directory or an image filing system file) 'pacman'.
2) Check for a file stamped 'data' called 'pacman' - this file would be a zip file, but as it wasn't
stamped as an archive, the image filing system would not see it. If this was file
found, MAME's internal zipfile routines would be used with file to extract the contents as
and when needed.
3) as for 2, but for a filename with a /zip extension (pacman/zip in this case)
4) as for 1, but with a /zip extension (pacman/zip).
The above two being useful for files held in a DOS partitiion or similar.
It would repeat the above combinations with all your currently set paths in
the ROMS, SAMPLES or whatever directories as set in mame/cfg (or *just*
romdir if you use -romdir, which is deprecated anyway).
*before* 23 Oct 1998, file checking was similar to the above but with some
(more than one ;-) ) bugs...
Anyway, the situation now is that there are few enough bugs to be able to use
the native MAME zip routines as often as possible. Why? Speed in many cases -
when -verifyroms does CRC32 checking on ROM image contents, where it uses
it's own zipfile checking, it doesn't have to load or decompress the files to
verify the checksum, because the checksum for the file is stored as a CRC32
value in the zipfile itself, which it has direct access to. It also
standardises against other ports, which are now using the inbuilt routines as
much as possible (overriding ZipMagic, for example).
The result now will be that given the above example, if the pacman directory
was an image file and not just a standard RISC OS directory, the internal
zipfile routines would be used, and not the image file system's routines.
Because -verifyroms checks the CRC32 value stored for the file in a zipfile,
-verifyroms could report the PROM files as being correct (because the
checksums match) even if the file can't be decompressed (due to disc error or
internal zip corruption). In this case, manually decompressing the files into
a standard directory and then running MAME is the safest bet, simply because
corruption in decompressed data affects the data length more often than not,
and a program loading a file through an image filing system which gives the
program more data than it expected can cause it to crash. When not using the
internal zipfile routines, -verifyroms is forced to read the whole file and
check it's CRC32 value, which is slower.
Note that if the above searching takes place within subdirectories of an
image file, MAME sees these as standard directories, because technically they
are - they are just directories, and not files.
Sound pitch should be nearer correct - not perfect, but nearer correct than it
has been over the last few releases. Hopefully I can nail it next time when I get
more time - I really need bug reports from this beta, especially if you are
having problems with screen update in some games (in which case sending me
the error/log file from mame xxx -log would help a lot...)
Note that DACSpt8 is new, and incompatible with the DACSpt8 supplied with the
current test 3 of SNES9X and MESS 0.2b4.
ZIP files *must* now be settype'd to Archive (DDC) for them to be treated as
archives, regardless of whether you use an image filing system or not. This
is how I check whether a file should be auditted as a plain file or checked
as a zip file. Also, do not use non-zip-deflated files with filetype DDC for
PROM directories! Damn, if only archive filetypes weren't composites of a million
different *actual* formats...
In fact, if you get trouble, ensure you're not making PROM directories another image
filing system type (eg TBAFS archive) though there should be no need for you to want
to do this.